Use of Payment Card Rewards Points for an Electronic Cash Transfer

ABSTRACT

A computer-implemented technique for applying rewards points associated with a payment card is disclosed. A computer system stores information associated with a person&#39;s payment card, such as a credit or debit card, including information indicative of rewards points associated with the card. The computer system then receives from a remote device a first message indicative of a transaction between the person and another entity. The transaction includes a payment of a specified amount from the person to the other entity. In some embodiments the transaction has already been completed, and the computer system causes rewards points to be applied to it post-transaction. In other embodiments the transaction has not yet been executed and may be a requested cash transfer. The computer system determines how many rewards points correspond to the specified amount and causes the rewards points to be used for at least a portion of the transaction amount.

RELATED APPLICATIONS

This application claims the benefit of U.S. patent application Ser. No.14/506,541 filed Oct. 3, 2014 which claims priority from U.S.provisional patent application No. 62/049,298, filed on Sep. 11, 2014,which are incorporated by reference herein in their entirety.

FIELD OF THE INVENTION

The present invention pertains to machine-implemented techniques forfacilitating and making payments, and more particularly, to a techniquefor applying rewards points associated with a payment card to a paymenttransaction.

BACKGROUND

Many credit cards have rewards programs that are designed as incentivesfor cardholders to use their cards more frequently and for largepurchases. A cardholder (consumer) typically earns rewards points on hisor her credit card by making purchases with the credit card and canredeem rewards points for merchandise or services, or can use them tooffset the card's unpaid balance.

One way of redeeming rewards points for good or services is for thecardholder to request a merchant to apply rewards points from his or hercredit card to a transaction (e.g., a purchase) at the time of checkoutfor the transaction, such as when the cardholder provides his or hercredit card information to the merchant. That approach is not optimal,however, because consumers often forget about their rewards points whenmaking purchases and therefore neglect to use their points. Further,when making a purchase, a consumer may not know his or her rewardspoints balance or may be unsure of whether the balance is sufficient tocover the purchase price (rewards points often do not have a one-to-onerelationship with the local currency). Likewise, a consumer may beunsure of whether their rewards points can be redeemed for the type ofgoods or services being purchased.

As a result, consumers tend to accumulate rewards points on their creditcards but redeem them infrequently. Consequently, credit card rewardsprograms may not be as effective as they were intended to be, atencouraging consumers to use their credit cards.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the present invention are illustrated by wayof example and not limitation in the figures of the accompanyingdrawings, in which like references indicate similar elements.

FIG. 1 illustrates an environment in which the rewards points techniqueintroduced here can be implemented.

FIG. 2 illustrates an example of internal elements of the paymentservice system (PSS).

FIGS. 3A through 3C show illustrative display screens on a mobiledevice, associated with a digital interactive receipt including rewardspoints information.

FIG. 4 shows an illustrative display screen on a mobile device,associated with an itemized digital interactive receipt includingrewards points information.

FIG. 5 is a flow diagram showing an example of a process forpost-transaction application of rewards points.

FIGS. 6A through 6C show examples of display screens on mobile device,associated with an electronic cash transfer.

FIG. 7 is a flow diagram showing an example of a process for applyingrewards points to an electronic cash transfer.

FIG. 8 illustrates a hardware architecture of a processing system thatcan be used to implement any of the devices mentioned herein, such as auser device, a point-of-sale (POS) system or the payment service system(PSS).

DETAILED DESCRIPTION

In this description, references to “an embodiment”, “one embodiment” orthe like, mean that the particular feature, function, structure orcharacteristic being described is included in at least one embodiment ofthe technique introduced here. Occurrences of such phrases in thisspecification do not necessarily all refer to the same embodiment. Onthe other hand, the embodiments referred to also are not necessarilymutually exclusive.

Introduced here is a computer-implemented technique that makes it easierfor consumers to use rewards points earned by their payment cards. Inthe technique, a centralized server computer system that includes one ormore computers, collectively called the payment service system (PSS),stores information associated with a person's payment card (or multiplepayment cards), such as a credit and/or debit card, includinginformation indicative of rewards points associated with the card. Atsome point in time the PSS receives from a remote device a messageindicative of a completed credit card based transaction between theperson and another entity (e.g., another person or a business). Thetransaction includes a payment of a specified amount (transactionamount) from the person to the other entity. The PSS determines how manyrewards points of the card used in the transaction correspond to thetransaction amount and, if the cardholder so requests, causes therewards points to be used to satisfy at least a portion of thetransaction amount. The PSS may do this in response to an expressrequest from the person (the cardholder) in relation to that specifictransaction, or it may do it automatically (e.g., according to apreviously-specified user preference or a default setting or policy).

Notably, the technique can be applied to a particular transaction in apost-transaction manner (i.e., after the transaction is complete betweenthe merchant and the consumer), thereby avoiding at least some of thedisadvantages of the conventional points redemption method describedabove. For example, in some embodiments the transaction has already beencompleted when the PSS receives a transaction message indicative of thetransaction. In such embodiments the transaction message may originatefrom a merchant's point-of-sale (POS) terminal or the issuing bank of aconsumer's card and may be an indication of a completed purchase by theconsumer using the consumer's credit card. In such cases the PSS maysend an interactive digital receipt to a user device of the consumer(e.g., a smartphone, tablet computer, notebook computer, desktopcomputer, or the like). Alternatively, the PSS may send the user devicea message that enables the consumer to access and retrieve theinteractive digital receipt.

The interactive digital receipt, when displayed by the consumers' userdevice, includes the transaction amount (e.g., purchase price), thenumber of points that correspond to the transaction amount, and a promptfor the consumer to provide an input indicating his or her request toapply the rewards points to the transaction. In response to such inputby the consumer, the user device sends a message to the PSS, whichapplies the rewards points to the transaction, or to a portion of thetransaction amount specified by the consumer. The PSS may do this by,for example, causing some or all of the transaction amount to be voidedfrom the transaction (assuming the transaction has not yet been fundedby the card-issuing bank) or by causing reversal of payment of some orall of the transaction amount (assuming the transaction has already beenfunded by the issuing bank). The PSS can communicate with the issuingbank directly or through a third party, for purposes of applying therewards points to the transaction.

The interactive digital receipt may include a list of items involved inthe purchase (i.e., a “shopping basket” list) and the correspondingnumber of rewards points for each item (tax may also be factored in).Consequently, the consumer can request, via the interactive digitalreceipt, the PSS to apply rewards points to only a specified portion ofthe purchase price, e.g., to a portion corresponding to only one or morespecified items in the purchase.

In some embodiments, the PSS may automatically apply rewards points tosome or all of the transaction amount, i.e., without waiting for arequest to do so from the consumer for that transaction.

Further, in some embodiments, the PSS tracks multiple types of rewardspoints associated with the consumer's credit card and enables theconsumer to apply rewards points from any one or more of those multiplecategories, or even from multiple different cards, to a particulartransaction.

In some embodiments, the technique introduced here also enables a personto use credit card rewards points for at least a portion of a cashtransfer from his or her bank account to the bank account of anotherperson or entity. For example, in some embodiments the PSS stores notonly information about a person's credit card, including rewards pointsinformation, but also information about a bank account and associateddebit card of the person. In such embodiments, the initial messagereceived by the PSS is an electronic message from the person's devicerepresenting a request to make a cash payment of a specified amount toanother person or other entity (e.g., a business). The PSS thendetermines how many rewards points correspond to the specified paymentamount. Optionally, before applying the rewards points to the payment(cash transfer), the PSS may send a message to the payer's device,informing him or her of the exact number of rewards points correspondingto the specified transfer amount, and asking the person to indicatewhether he or she wants rewards points to be used for the cash transfer(and, optionally, how many points should be used). If the person soindicates by an input to his or her user device, the user device sends amessage to the PSS, in response to which the PSS causes at least aportion of the cash transfer amount to be satisfied from the payer'srewards points. This action can include causing at least some of thecash transfer amount to be satisfied from the payer's credit cardrewards points and deposited to an account of the payee (e.g., by usingdebit card information of the payee's bank account), and causing anyremainder of the cash transfer amount to be debited from the payer'sbank account (e.g., by using the payer's debit card information) anddeposited to an account of the payee.

FIG. 1 illustrates an environment in which the rewards points techniqueintroduced here can be implemented. The environment includes amerchant's POS system 104 and a mobile device 102 of a consumer 101(also called “customer” or “user”). The mobile device 102 can be, forexample, a smartphone, tablet computer, notebook computer, or any otherform of mobile processing device. Alternatively, in some embodiments themobile device 102 can be replaced with a non-mobile user device, such asa standard desktop computer.

The illustrated environment also includes a computer system 114 of themerchant's acquiring bank (“acquirer”) for credit card transactions, acomputer system 118 of the issuing bank (“issuer”) of the user's paymentcard 18, a computer system 116 of a card payment network (e.g., Visa orMasterCard), and a computer system 108 of a payment service. The paymentcard 18 can be a conventional credit card, for example. Alternatively,the payment card 18 can be a debit card, automatic teller machine (ATM)card, or the like. Each of the aforementioned computer systems caninclude one or more distinct physical computers and/or other processingdevices which, in the case of multiple devices, can be connected to eachother through one or more wired and/or wireless networks.

All of the aforementioned devices are coupled to each other through aninternetwork 106, which can be or include the Internet and one or morewireless networks (e.g., a cellular telecommunications network and/orWiFi network).

The PSS 108 in at least some embodiments includes one or more servercomputers programmed to provide payment related services to consumers,including at least some aspects of the rewards points techniqueintroduced here. The PSS 108 can be operated by a payment service 110,which can be a business enterprise that provides and facilitates varioustypes of payment related services for consumers. Consumers can registerwith the payment service 110 to receive such services, and suchconsumers are referred to herein as “registered users.” One type ofservice provided by the payment service 110 is enabling registered usersto apply rewards points associated with their payment cards toalready-completed transactions, as described further below.

The PSS 108 stores information about registered users providedvoluntarily by them, such as their names, addresses, credit cardnumbers, debit card numbers, bank account numbers, mobile telephonenumbers, email addresses, etc. Further, the PSS 108 stores rewardspoints information associated with registered users' payment cards. ThePSS 108 may obtain current rewards points balances of registered usersfrom the corresponding card issuers (e.g., issuer 118) directly orthrough a third party. For example, the PSS 108 may use a publishedapplication programming interface (API) of a card issuer to obtaincurrent rewards points balances for credit cards of registered users.

The PSS 108 also stores information about devices used by its registeredusers, particularly mobile devices (e.g., smartphones and tabletcomputers), but also potentially including users' conventional devicessuch as desktop computers. Hence, the PSS 108 can communicate with auser's device 102 over internetwork 106.

The rewards points technique introduced here can be applied with bothtraditional card-present transactions (i.e., transactions involvingreading a customer payment card present at the merchant's POS) as wellas “cardless” payment card transactions, the latter of which aredescribed further below. In a traditional card-present payment cardtransaction, the merchant swipes the consumer's payment card 18 througha card reader 105 at the POS system 104. The POS system 104 sends dataread from the card (e.g., the consumer/cardholder's name, credit cardnumber, expiration date and card verification value (CVV)) to thecomputer system 114 of the merchant's acquirer (hereinafter “acquirer114”). The acquirer 114 sends this data to the computer system 116 ofthe card payment network (e.g., Visa or MasterCard) (hereinafter “cardpayment network 116”), which forwards the data to the computer system118 of the issuing bank (hereinafter “issuer 118”). If the transactionis approved by the issuer 118, a payment authorization message is sentfrom the issuer 118 to the merchant POS system 104, via a path generallyopposite that described above.

Note that in this description, any references to sending or transmittinga message, signal, etc. to another device (recipient device) means thatthe message is sent with the intention that its information contentultimately be delivered to the recipient device; hence, such referencesdo not mean that the message must be sent directly to the recipientdevice. That is, unless stated otherwise, there can be one or moreintermediary entities that receive and forward the message/signal,either “as is” or in modified form, prior to its delivery to therecipient device. This clarification also applies to any referencesherein to receiving a message/signal from another device; i.e., directpoint-to-point communication is not required unless stated otherwiseherein.

The rewards points technique introduced here can also be applied withcardless payment card transactions. Just as registered users have arelationship with the payment service 110 (e.g., by preregistering),some merchants also may have a relationship with the payment service 110(e.g., by preregistering with the payment service 110), to enable theproviding of additional services to consumers. Such merchants arereferred to herein as “registered merchants.” Registered merchants mayuse specially-configured POS systems (including software configured tocommunicate with the PSS 108) to enable registered consumers to usetheir payment cards to pay for purchases at a merchant's physicallocation, without the consumers having to have their cards in theirphysical possession at the time of the purchase, e.g., by using a“pay-by-name/pay-by-face” paradigm. Such transactions are called“cardless” payment card transactions herein. In general, in the case ofa transaction with a registered merchant, the PSS 108 can function as anintermediary between the registered merchant and the registeredmerchant's acquirer 114. Note, however, that the details of how a“cardless” payment card transaction can be performed are not germane tothe rewards points technique introduced here.

As noted above, the rewards points technique can be applied in apost-transaction manner to credit card transactions with non-registeredmerchants and to credit card transactions with registered merchants(e.g., cardless transactions). In either scenario, the PSS 108 mayreceive a transaction message indicative of a completed payment cardtransaction. In the context of this description, a transaction is deemedto be “complete” when the merchant's POS has received a messageindicating that the transaction has been authorized by the appropriatethird party (e.g., the card issuer), such that the consumer is deemed bythe merchant to have fully paid. In the case of a non-registeredmerchant, the PSS 108 may receive the transaction message from theconsumer's credit card issuer, as described above. If the transaction iswith a registered merchant, the PSS 108 may instead receive thetransaction message indicating the completed card transaction directlyfrom the registered merchant (e.g., in a “cardless” credit cardtransaction). In other embodiments, the PSS 108 may receive thetransaction message indicating the completed credit card transactionfrom some other entity.

The transaction message can include data descriptive of the transaction,such as the name of the cardholder, card number and expiration date,name and address of the merchant, total amount (payment amount) of thetransaction, date and time of the transaction, and a list of items(goods and/or services) purchased in the transaction and theirindividual prices (i.e., a “shopping cart” list). The PSS 108 can useinformation in the transaction message to enable post-transactionapplication of rewards points to the transaction amount, as describedfurther below. Note that the term “purchase” is used broadly herein torefer to any type of payment-based transaction and is not limited to asituation where an item changes ownership. Hence, a “purchase” in thisdescription also can include a lease or rental, or a transactioninvolving services, or the like. Likewise, the term “sale” (as in“point-of-sale”) also refers to any type of payment-orientedtransaction.

The PSS 108, in response to a transaction message indicating a completedpayment card based transaction involving a user 101, may send aninteractive digital receipt for the transaction to the user's mobiledevice 102 (or another designated device associated with the user 101),where it is displayed or output to the user in some other manner. Theinteractive digital receipt in some embodiments provides a graphicaluser interface (GUI) and may include both program code and data. Fromthe interactive digital receipt, the user can input a request, to thedevice 102, to apply rewards points associated with the user's creditcard to the subject transaction. The request is sent by the user device102 in a message to the PSS 108 via the internetwork 106 (which mayinclude a wireless telecommunications network). The PSS 108 then causesthe rewards points to be applied to the transaction.

FIG. 2 illustrates internal elements of the PSS 108 according to someembodiments. As illustrated, the PSS 108 includes a digital receiptgenerator 201, a rewards points computation module 202 and a paymentprocessing module 203. Additionally, the PSS 108 stores user information204, payment card information 205 and transaction information 206. Theuser information 204 and card information 205 may be stored in the samedatabase or in separate databases. The user information 204 and paymentcard information 205 are logically linked so as to associate each itemof card information with the corresponding user information. The userinformation 204 includes information about registered users, such astheir names, addresses and other contact information, and informationabout user devices of the users (e.g., mobile telephone numbers and/ormobile identification numbers (MINs)). The payment card information 205may include, for example, credit card information of registered users,such as credit card number, expiration date, card verification value(CVVs) and security codes. Other types of card information may also bestored by the PSS 108, such as debit card information, bank accountinformation, etc. The transaction information 206 may include, forexample, data such as transaction amount, items involved in atransaction, and/or data received from other entities (e.g., the cardnetwork or issuer), any/all of which can be used by the PPS 108 to linktogether transaction refunds, voids and/or rewards points transactions.

The main function of the digital receipt generator 201 is to generateinteractive digital receipts in response to card based transactionsinvolving registered users. More particularly, the digital receiptgenerator 201 generates digital receipts in response to receivingtransaction messages (e.g., from card issuers and/or registeredmerchant's POS systems) indicative of completed card based transactions(which may be card-present transactions or cardless transactions). Themain functions of the rewards points computation module 202 are todetermine (in response to a transaction message) the number of rewardspoints currently redeemable by a given user associated with a card usedin a recent transaction, and to determine the number of rewards pointscorresponding to the amount of the transaction. In this regard, therewards points computation module 202 may include logic to enable thePSS 108 to communicate with a card issuer's computer system directly orthrough a third party, to ascertain the number of rewards pointscurrently available to a registered user, and to notify the issuerwhenever rewards points are used for a transaction.

The main functions of the payment processing module 203 are to causeactual movement of funds and/or modification of transaction amounts inconnection with applying rewards points. This may occur in any ofseveral ways. For example, if a completed transaction has not yet been“captured” (i.e., the funds are being held by the issuer but have notyet been removed from the cardholder's account), then the paymentprocessing module 203 may cause authorization of the transaction to bevoided (e.g., by sending an electronic message to the issuing bank or bycausing the merchant's POS system to do so), in which case the paymentprocessing module 203 may request a new authorization for a lower amountif the rewards points are only being used for a portion of the totaltransaction amount. Alternatively, if the transaction has already beencaptured (i.e., the funds have been removed from the cardholder'saccount), then the payment processing module 203 may accomplish this bycausing at least a portion of the transaction amount to be refunded orreversed. Note that as used herein, “causing” an action to occur meansthat the causing entity either performs the action itself or initiates asequence of events that is ordinarily expected to lead to that action(which can be subject to satisfying certain intermediary conditions).Note that in some alternative embodiments, two or more of the digitalreceipt generator 201, the rewards points computation module 202 or thepayment processing module 203 can be combined into a single functionalmodule.

An example use scenario will now be described from a user's perspective,for at least one embodiment of the rewards points technique, withreference to FIGS. 3A through 3C. Assume that a registered user has justhad a meal at an establishment called Joe's Restaurant and has paid forthe meal with his credit card. Sometime after the credit cardtransaction is authorized (maybe only a few seconds I, or perhapsseveral hours later), the user receives an interactive digital receipton his smartphone from the PSS 108. The digital receipt may be, thoughis not necessarily, generated and sent to the user's smartphone by thePSS 108 after a tip was added to the restaurant bill, as assumed in thisexample for the sake of simplicity.

FIG. 3A shows an example of what the interactive digital receipt maylook like when displayed on a touchscreen of the user's smartphone. Thedigital receipt includes the name of the merchant (Joe's Restaurant),the total transaction amount ($45.25), and the date and time of thetransaction. Additionally, the digital receipt includes an indication ofthe number of rewards points (1,624) that corresponds to the transactionamount for the credit card that was used in the transaction (since thereis not necessarily a one-to-one relationship between a rewards point andthe applicable currency unit) and an indication of the total number ofrewards points currently available (redeemable) for that credit card.The interactive digital receipt further includes a “Use Points” buttonor other similar control that, when activated by the user, takes theuser to another screen, such as that illustrated in FIG. 38.

In the screen of FIG. 38, the user can simply press the “OK” button toapply the entire number of rewards points corresponding to thetransaction amount; or, the user can press another button 301 to takethe user to yet another screen, such as that shown in FIG. 3C, where theuser can specify a different (presumably smaller) number of rewardspoints to apply. For example, in the present example the user may wishto apply only 1,000 rewards points to the transaction rather than thefull 1,624 rewards points, thereby only paying for a portion of thetransaction with rewards points.

The interactive digital receipt can include an itemized list of goodsand/or services purchased in the transaction and their individualprices, i.e., a “shopping cart” list, as shown in the example of FIG. 4.The shopping cart information may have been obtained by the PSS 108 fromthe transaction message described above. In such an embodiment, theinteractive digital receipt can allow the user to select one or more ofthe individual items, to whose portion(s) of the total amount he wouldlike to apply corresponding amounts of rewards points. The PSS 108 cancalculate the appropriate number of rewards points for each item basedon each item's pro rata portion of the total transaction amount(factoring in tax if appropriate), or by any other suitable method. Thenumber of rewards points corresponding to each item can be indicatednext to each item on the interactive digital receipt, as shown in FIG.4. The selection can be made using any conventional GUI control, such asby setting a radio button for each item on or off.

In some embodiments, the PSS 108 can track rewards points balances andrelated information for multiple categories or types of rewards pointsfor a given card of a user, or for separate cards of a user.Consequently, in a similar manner to the itemization described above,the PSS 108 can present the user with the option to select one or moreof multiple rewards points categories/types, whose points he or shewishes to apply to a given transaction. Hence, the user can apply pointsfrom two or more different categories/types (and potentially, from twoor more different cards) to a given transaction.

FIG. 5 illustrates an example of a process that can be performed by thePSS 108 to implement the post-transaction rewards points techniquedescribed above. At step 501, the PSS 108 receives a transaction messagerelating to a completed card-based transaction of a registered user. Thetransaction message includes, for example, cardholder information aboutthe user (e.g., cardholder name), merchant information (e.g., merge nameand address), transaction amount and (optionally) shopping basketinformation. Next, at step 502 the PSS 108 looks up and reads, from itsinternal databases, user information and card information, correspondingto the information in the transaction message. The PSS 108 then at step503 computes the number of rewards points equal to the transactionamount, based on a conversion factor published by the card issuer. Atstep 504 the PSS 108 communicates with the card issuer to determine thenumber of redeemable rewards points currently associated with the user'scard that was involved in the transaction. This may be done by accessinga published API of the card issuer's computer system. Assuming the userhas some redeemable rewards points, the PSS 108 at step 505 generates aninteractive digital receipt containing transaction information andrewards points information, such as described above (or if the user hasno redeemable rewards points, the process instead just ends at thispoint).

Next, at step 506 the PSS 108 sends to a user device of the consumer amessage containing the interactive digital receipt, or for enabling theuser device to access, retrieve and output the interactive digitalreceipt. In some cases the user device may be a mobile device of theconsumer, whose telephone number was previously provided to the PSS 108by the user and stored in a database of the PSS 108. In other cases theuser device may be a conventional desktop computer or other devicebelonging to the user.

The interactive digital receipt can be sent to the user device in any ofvarious formats and communication protocols, such as by email, shortmessaging service (SMS) message, multimedia messaging service (MMS)message, or the like. In some embodiments, the PSS 108 may simply sendthe user (e.g., via e-mail or SMS message) a hyperlink to a locationwhere the interactive digital receipt is stored, which is downloaded tothe user device only when the user activates the hyperlink. The user mayhave previously set a preference indicating which user device or devicesshould receive interactive digital receipts or related messages from thePSS 108.

After sending the interactive digital receipt (or a message for enablingaccess to it), if the PSS 108 then does not receive a request to userewards points for the transaction from the user within a predeterminedtimeout period (step 507), the process simply ends without applying anyrewards points to the transaction. Note that in some embodiments, theuser may have the option to set a preference to apply any availablerewards points to every transaction or to certain types of transactions,by default. If, however, the PSS 108 does receive a request to userewards points within the timeout period, then the PSS 108 attempts toauthenticate the request at step 508. Authentication may be done by, forexample, requiring the user to input the payment card's CVV or someother personal information into the GUI when submitting the request,which is then compared by the PSS 108 to information in the PSS'sdatabases. If the user's request is authenticated, the PSS 108 thencauses the specified number of rewards points to be used to offset atleast a portion of the transaction amount (depending upon how manyrewards points the user indicated should be applied) at step 509. Insome embodiments, step 509 is accomplished by the PPS 108 sending two ormore messages to the issuer, either directly or through a third-party.For example, in some embodiments the PPS 108 sends to the issuer (eitherdirectly or through third-party) at least one request to deduct theappropriate number of rewards points from the user's account.Additionally, the PPS 108 sends to the issuer (either directly orthrough third-party) request to reconcile transaction amount. This couldinclude reversal of the hold if the transaction has been authorized butnot yet captured, or it could include reversal of the transaction andrefunding of the money, if the transaction has already been captured.Additionally, this may be for the entire amount of the transaction orsome partial amount, depending on how many rewards points were used, asindicated above.

If the request fails authentication, the PSS 108 instead just sends anerror message to the user's device at step 510.

In some embodiments, the technique introduced here also enables aregistered user to use credit card rewards points for a direct cashtransfer from the person's bank account to the bank account of anotherperson or entity. For example, in some embodiments the PSS 108 storesnot only information about a person's credit card, including rewardspoints information, but also information about the person's bank accountand an associated debit card. Such embodiments are now described furtherwith reference to FIGS. 6A through 6C and FIG. 7.

In a cash transfer embodiment, instead of initially receiving atransaction message indicative of a completed transaction with themerchant, the initial message received by the PSS 108 may be anelectronic message, from a registered user's device, representing arequest to make a cash payment of a specified amount directly from theuser's bank account to the bank account of another person or otherentity. The user may have initiated such a request on his smartphone orother mobile device by using a mobile application (hereinafter the “cashapp”) on the mobile device, associated with the payment service 110. Thecash app may take the user through a series of screens, examples ofwhich are shown in FIGS. 6A through 6C.

As shown in FIG. 6A, upon starting the cash app the user (the payer)enters the amount of cash to be sent. The user next specifies a person(or other entity) (the payee or recipient) to whom the cash is to besent. As shown in FIG. 68, the user may select the payee from a contactlist, e.g., by name and/or email address. The payee can be, but is notnecessarily, another registered user of the payment service who haspreviously provided his or her bank account information (e.g., includingdebit card information) to the PSS 108. If the payee is not a registereduser, he will be invited by the PSS 108 to become a registered user inorder to receive the cash transfer.

Additionally, the payer can input a brief memo indicating the purpose ofthe cash transfer, as shown in FIG. 6C, (e.g., in the “For” field),which will be included in the request and a subsequent message sent tothe payee. Once all the information is entered, the payer can press“Send,” which causes an email or other type of electronic message(“request message”) to be sent by the user device to the PSS 108. Therequest message contains at least identification information of thepayer, the requested payment amount, and identification information ofthe recipient/payee. The request message is analogous to the transactionmessage in the consumer/merchant embodiments described above, at leastin terms of its effect. Upon receiving the request message, the PSS 108sends a corresponding message to the payee, informing him or her of thepending cash transfer. If the payee is not a registered user of thepayment service, the payee is invited to become one in order to receivethe payment, including providing his or her debit card information tothe PSS 108.

An example of the remainder of the process is described now in relationto FIG. 7. Initially, the PSS 108 receives the request message from theuser device of the payer at step 701. At step 702 the PSS 108 looks upin its databases payer information and card information associated withthe payer.

For purposes of enabling a cash transfer, it is assumed that the payerhas previously provided to the PSS 108 detailed information about his orher bank account and an associated debit card. Hence, the PSS 108 canuse the conventional debit card “rails” to effect such a transfer.Additionally, the user has previously provided the PSS 108 withinformation of a second payment card of the user that earns rewardspoints, which in this example is assumed to be (but is not necessarily)a credit card of the payer. Note that unlike in the consumer/merchantembodiments described above, however, the second payment card has notyet been used in relation to the requested cash transfer.

The PSS 108 then at step 703 computes the number of rewards points ofthe second card that equal the requested payment amount, using a knownconversion factor. Next, at step 704 the PSS 108 communicates with thecard issuer to determine the number of redeemable rewards pointscurrently associated with the second payment card. Assuming the user hassome redeemable rewards points, the PSS 108 next at step 705 generates amessage containing rewards points information, and a prompt the user toindicate whether the awards points should be used for the cash transfer.In particular, in a manner similar to the digital receipt describedabove, this message can indicate the number of rewards points thatcorresponding to the requested cash transfer amount, as well as thetotal number of redeemable awards points available to the payer.

After sending the message, if the PSS 108 then does not receive arequest to use rewards points for the payment from the user within apredetermined timeout period (step 707), the process simply continues bycausing the cash transfer to be executed at step 710. This may beaccomplished, for example, by debiting the payment amount from thepayer's bank account and depositing the funds into the payee's bankaccount. In other embodiments, the user may have the option to set apreference to apply any available rewards points to every cash transfer,by default.

If the PSS 108 does receive a request from the payer to use rewardspoints for the payment within the timeout period, however, then the PSS108 attempts to authenticate the payer's request at step 708.Authentication may be done, for example, in the same manner describedabove in the consumer/merchant examples. If the request failsauthentication, the PSS 108 instead just sends an error message to theuser's device at step 711. If the user's request is authenticated, thePSS 108 then at step 709 causes the specified number of rewards pointsto be used to offset at least a portion of the transaction amount(depending upon how many rewards points the user indicated should beapplied). This action can include causing at least some of the cashtransfer amount to be satisfied from the payer's credit card rewardspoints and deposited to the payee's bank account (e.g., by using thepayee's debit card information), and causing any remainder of thespecified transfer amount to be debited from the payer's bank account(e.g., by using the payer's debit card information) and deposited to thepayee's bank account in similar manner.

In certain embodiments, the issuer of the payer's credit card maintainsa pool of funds associated with its credit card rewards points program,and rewards points can be redeemed for funds from that pool. Hence, instep 709 above, satisfying some or all of a cash transfer amount from apayer's credit card rewards points can be accomplished in any of atleast three ways: For example, the funds can be obtained by the PSS 108directly from the issuer's rewards points pool of funds such asmentioned above. Alternatively, the funds can be debited from thecardholder's bank account by the PSS 108 and subsequently reimbursedfrom the issuer's rewards points pool of funds. As yet anotheralternative, the funds can be obtained by the PSS 108 as a cash advancefrom the cardholder's credit card account and then subsequentlyreimbursed from the issuer's rewards points pool of funds. It will berecognized that various other approaches are also possible.

FIG. 8 illustrates at a high-level an example of a hardware architectureof a processing system that can be used to implement any of the devicesreferred to above, such as a user device of a registered user, amerchant's POS system, the PPS 108, etc. Any of these devices each caninclude multiple instances of an architecture such as shown in FIG. 8(e.g., multiple computers), particularly server-based systems such asthe PPS 108, and such multiple instances can be coupled to each othervia one or more networks.

In the illustrated embodiment, the architecture 800 includes one or moreprocessors 810, memory 811, one or more communication device(s) 812, oneor more input/output (1/0) devices 813, and one or more mass storagedevices 814, all coupled to each other through an interconnect 815. Theinterconnect 815 may be or include one or more conductive traces, buses,point-to-point connections, controllers, adapters and/or otherconventional connection devices. The processor(s) 810 control theoverall operation of the processing device 800 and can be or include,for example, one or more general-purpose programmable microprocessors,digital signal processors (DSPs), mobile application processors,microcontrollers, application specific integrated circuits (ASICs),programmable gate arrays (PGAs), or the like, or a combination of suchdevices.

Memory 811 can be or include one or more physical storage devices, whichmay be in the form of random access memory (RAM), read-only memory (ROM)(which may be erasable and programmable), flash memory, miniature harddisk drive, or other suitable type of storage device, or a combinationof such devices. The mass storage device (s) 814 can be or include oneor more hard drives, digital versatile disks (DVDs), flash memories, orthe like. Memory 811 and/or mass storage 814 can store (individually orcollectively) data and instructions that configure the processor(s) 810to execute operations to implement the techniques described above. Thecommunication devices 812 may be or include, for example, an Ethernetadapter, cable modem, Wi-Fi adapter, cellular transceiver, basebandprocessor, Bluetooth or Bluetooth Low Energy (BLE) transceiver, or thelike, or a combination thereof. Depending on the specific nature andpurpose of the processing device 800, the 1/0 devices 813 can includedevices such as a display (which may be a touch screen display), audiospeaker, keyboard, mouse or other pointing device, microphone, camera,etc. Note, however, that such 1/0 devices may be unnecessary if theprocessing device 800 is embodied solely as a server computer.

In the case of a user device, the communication devices 812 can be orinclude, for example, a cellular telecommunications transceiver (e.g.,3G or 4G/LTE), Wi-Fi transceiver, baseband processor, Bluetooth or BLEtransceiver, or the like, or a combination thereof. In the case of thePSS 108, the communication devices 812 can be or include, for example,any of the aforementioned types of communication devices, a wiredEthernet adapter, cable modem, DSL modem, or the like, or a combinationof such devices.

Although the present invention has been described with reference tospecific exemplary embodiments, it will be recognized that the inventionis not limited to the embodiments described, but can be practiced withmodification and alteration within the spirit and scope of the appendedclaims. Accordingly, the specification and drawings are to be regardedin an illustrative sense rather than a restrictive sense.

1. (canceled)
 2. A method comprising: receiving, by one or more serversof a payment service, transaction data associated with a pendingtransaction between a customer and a merchant of a plurality ofmerchants, wherein the transaction data includes at least a paymentamount, a payment instrument identifier corresponding to a paymentinstrument associated with the customer, and a payment reader identifiercorresponding to a payment reader of a plurality of payment readersassociated with the merchant; determining, based at least in part on (i)the payment instrument identifier and (ii) the payment readeridentifier, and by the one or more servers of the payment service,rewards available for redemption by the customer in association with thetransaction with the merchant; causing, by the one or more servers ofthe payment service and on a customer device associated with thecustomer or a point-of-sale (POS) device associated with the merchant,display of an indication that the rewards are available for redemptionin association with the transaction; receiving, by the one or moreservers of the payment service and from the customer device or the POSdevice, a request to redeem at least a portion of the rewards;determining, by the one or more servers of the payment service, anupdated payment amount based at least in part on the payment amount andat least the portion of the rewards redeemed; causing, by the one ormore servers of the payment service, display of the updated paymentamount on at least one of the customer device or the POS device;modifying, by the one or more servers of the payment service, therewards available for redemption based at least in part on at least theportion of rewards redeemed in the transaction; and processing, by theone or more servers of the payment service, payment for the transactionusing the updated payment amount.
 3. The method as claim 2 recites,wherein the rewards available for redemption are additionally redeemableat one or more other merchants of the plurality of merchants.
 4. Themethod as claim 2 recites, wherein the payment reader comprises a firstpayment reader, wherein the rewards are redeemable at the first paymentreader and not at a second payment reader associated with the merchant.5. The method as claim 4 recites, wherein the merchant comprises a firstmerchant, and wherein the rewards available for redemption are alsoredeemable at a second payment reader of a second merchant of theplurality of merchants, wherein the second payment reader is associatedwith another payment reader identifier.
 6. The method as claim 2recites, further comprising: storing, in a data store associated withthe payment service, associations between individual payment readeridentifiers and locations of the corresponding payment readers.
 7. Themethod as claim 2 recites, wherein the transaction data further includesan indication of one or more items being purchased in the transaction.8. The method as claim 7 recites, wherein causing display of theindication that the rewards are available for redemption comprisescausing display of an indication of a number of rewards pointscorresponding to each item of the one or more items.
 9. The method asclaim 2 recites, wherein the rewards available for redemption areassociated with the payment instrument, and wherein determining therewards available for redemption comprises receiving an indication ofthe rewards from an issuer of the payment instrument via an applicationprogramming interface (API) of a computing system of the issuer.
 10. Themethod as claim 2 recites, wherein determining the rewards available forredemption comprises receiving an indication of the rewards availablefor redemption from a computing system of the merchant.
 11. The methodas claim 2 recites, wherein modifying the rewards available forredemption comprises transmitting, by the one or more servers and to acomputing system of an issuer of the payment instrument, a request tochange the rewards available for redemption by the rewards redeemed inthe transaction.
 12. The method as claim 2 recites, wherein the rewardsavailable for redemption are based at least in part on one or more oflocation of the transaction, date of the transaction, time of thetransaction, merchant type of the merchant, or type of an item beingpurchased in the transaction.
 13. A system comprising: one or moreprocessors; and one or more computer-readable media storing instructionsexecutable by the one or more processors, wherein the instructionsprogram the one or more processors to perform actions comprising:receiving transaction data associated with a transaction between acustomer and a merchant of a plurality of merchants, wherein thetransaction data indicates the merchant, a payment amount, a paymentreader identifier corresponding to a payment reader of a plurality ofpayment readers associated with the merchant, and a payment instrumentidentifier corresponding to a payment instrument associated with thecustomer; determining, based at least in part on (i) the payment readeridentifier and (ii) the payment instrument identifier, a customer deviceassociated with the customer and rewards available for redemption by thecustomer in association with the transaction; causing, on the customerdevice, display of a notification regarding the rewards available forredemption; receiving, from the customer device, a request to redeem atleast a portion of the rewards; based at least in part on the request,determining an updated payment amount based at least in part on thepayment amount and the at least the portion of the rewards; processingthe updated payment amount as payment for the transaction; and causing areduction of the rewards available for redemption based at least in parton the at least the portion of rewards redeemed in the transaction. 14.A system as claim 13 recites, wherein the payment reader comprises afirst payment reader, the merchant comprises a first merchant, and thepayment reader identifier comprises a first payment reader identifier,wherein the rewards are redeemable at a second payment reader associatedwith a second merchant and a second payment reader identifier but arenot redeemable at a third payment reader associated with the firstmerchant and a third payment reader identifier.
 15. A system as claim 13recites, wherein determining the rewards comprises receiving anindication of the rewards from an issuer of the payment instrument viaan application programming interface (API) of a computing system of theissuer.
 16. A method comprising: receiving transaction data associatedwith a transaction between a customer and a merchant of a plurality ofmerchants, wherein the transaction data indicates the merchant, apayment amount, a point-of-sale (POS) device identifier corresponding toa POS device of a plurality of POS devices associated with the merchant,and a payment instrument identifier corresponding to a paymentinstrument associated with the customer; determining, based at least inpart on (i) the payment reader identifier and (ii) the paymentinstrument identifier, a customer device associated with the customerand rewards available for redemption by the customer in association withthe transaction; processing an updated payment amount as payment for thetransaction, wherein the updated payment amount is based at least inpart on the rewards available for redemption and the payment amount; andcausing a reduction of the rewards available for redemption based atleast in part on rewards redeemed in the transaction.
 17. A method asclaim 16 recites, wherein the rewards available for redemption compriserewards points earned by use of credit extended to the customer by themerchant.
 18. A method as claim 16 recites, wherein causing thereduction of the rewards available for redemption comprises causing thereduction by an amount specified by the customer at or before a time ofthe transaction.
 19. A method as claim 16 recites, further comprising:responsive at least in part to determining the rewards available forredemption, causing display of, on the customer device or the POSdevice, a notification regarding the rewards available for redemption;and receiving, from the customer device or the POS device, a request toredeem at least a portion of the rewards available for redemption,wherein processing the updated payment amount is responsive at least inpart to receiving the request.
 20. A method as claim 16 recites, whereinprocessing the payment using the updated payment amount is based atleast in part on registration with the payment service by the customer.21. A method as claim 16 recites, further comprising determining, basedat least in part on the payment reader identifier, at least one merchantidentifier of a plurality of merchant identifiers.